Managing a complex store can be tricky and Li Hau Tan has 3 tips for optimizing complex stores.

Let's begin by showing a demo application.

<script>
	import Navbar from "./Navbar.svelte";
	import TodoList from "./TodoList.svelte";
</script>

<Navbar />

<TodoList />

First off, we are using markUpdate.js which shows where our states are getting updated by showing them with a red border. We can see this causes a problem because changing our profile name changes the state everywhere even though the profile name doesn't really have anything to do with the todos or notifications. This is also something we can improve.

For the bug itself we can search for $data.todos and see where we are changing it, but we don't find the bug that way… 😵

Debugging complex stores like this can be very hard since we can change the store from all components in basically any way we like .

One way we could improve this is to introduce an action that is the only thing that is allowed to edit the store. If we do this we can trace and find from where the action to edit the store came from.

Our error is in the component Notification where we left in some debugging code by mistake:

<!-- 
  if ($data.notifications.length === 3) $data = { ...$data, todos: [] };
 -->

Let's make a better version of our app by:

• making smaller stores, for example user doesn't need to be in the main store
• creating derived stores for things that only require small things like "length of todos" to avoid extra update cycles
• putting all our functions that modify the store in one place !

<script>
	import Navbar2 from "./Navbar2.svelte";
	import TodoList2 from "./TodoList2.svelte";
</script>

<Navbar2 />

<TodoList2 />

After editing data2.js we can see that adding a smaller user store helped because now when we edit the user name only the navbar updates .

In the same way when toggling a todo to be done the navbar doesn't update because we're using derived stores for the smaller .length and so data .

Here are Li Hau Tan's tips:

Tip 1:

If you have a complex state, avoid manipulating the writable store directly.

Use state management libraries, such as state machines or reducers to help manage the state changes.

Tip 2:

Have a small self-contained store.

Tip 3:

If you have a large store, create a derived store out of it, so your component does not have to subscribe to all changes made to the store.

Making the store immutable or proxy-based can allow us to subscribe to part of the store too!